<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>AtomPub Multipart Media Resource Creation</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="AtomPub Multipart Media Resource Creation">
<meta name="generator" content="xml2rfc v1.33 (http://xml.resource.org/)">
<style type='text/css'><!--
        body {
                font-family: verdana, charcoal, helvetica, arial, sans-serif;
                font-size: small; color: #000; background-color: #FFF;
                margin: 2em;
        }
        h1, h2, h3, h4, h5, h6 {
                font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
                font-weight: bold; font-style: normal;
        }
        h1 { color: #900; background-color: transparent; text-align: right; }
        h3 { color: #333; background-color: transparent; }

        td.RFCbug {
                font-size: x-small; text-decoration: none;
                width: 30px; height: 30px; padding-top: 2px;
                text-align: justify; vertical-align: middle;
                background-color: #000;
        }
        td.RFCbug span.RFC {
                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
                font-weight: bold; color: #666;
        }
        td.RFCbug span.hotText {
                font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
                font-weight: normal; text-align: center; color: #FFF;
        }

        table.TOCbug { width: 30px; height: 15px; }
        td.TOCbug {
                text-align: center; width: 30px; height: 15px;
                color: #FFF; background-color: #900;
        }
        td.TOCbug a {
                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
                font-weight: bold; font-size: x-small; text-decoration: none;
                color: #FFF; background-color: transparent;
        }

        td.header {
                font-family: arial, helvetica, sans-serif; font-size: x-small;
                vertical-align: top; width: 33%;
                color: #FFF; background-color: #666;
        }
        td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
        td.author-text { font-size: x-small; }

        /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
        a.info {
                /* This is the key. */
                position: relative;
                z-index: 24;
                text-decoration: none;
        }
        a.info:hover {
                z-index: 25;
                color: #FFF; background-color: #900;
        }
        a.info span { display: none; }
        a.info:hover span.info {
                /* The span will display just on :hover state. */
                display: block;
                position: absolute;
                font-size: smaller;
                top: 2em; left: -5em; width: 15em;
                padding: 2px; border: 1px solid #333;
                color: #900; background-color: #EEE;
                text-align: left;
        }

        a { font-weight: bold; }
        a:link    { color: #900; background-color: transparent; }
        a:visited { color: #633; background-color: transparent; }
        a:active  { color: #633; background-color: transparent; }

        p { margin-left: 2em; margin-right: 2em; }
        p.copyright { font-size: x-small; }
        p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
        table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
        td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }

        ol.text { margin-left: 2em; margin-right: 2em; }
        ul.text { margin-left: 2em; margin-right: 2em; }
        li      { margin-left: 3em; }

        /* RFC-2629 <spanx>s and <artwork>s. */
        em     { font-style: italic; }
        strong { font-weight: bold; }
        dfn    { font-weight: bold; font-style: normal; }
        cite   { font-weight: normal; font-style: normal; }
        tt     { color: #036; }
        tt, pre, pre dfn, pre em, pre cite, pre span {
                font-family: "Courier New", Courier, monospace; font-size: small;
        }
        pre {
                text-align: left; padding: 4px;
                color: #000; background-color: #CCC;
        }
        pre dfn  { color: #900; }
        pre em   { color: #66F; background-color: #FFC; font-weight: normal; }
        pre .key { color: #33C; font-weight: bold; }
        pre .id  { color: #900; }
        pre .str { color: #000; background-color: #CFF; }
        pre .val { color: #066; }
        pre .rep { color: #909; }
        pre .oth { color: #000; background-color: #FCF; }
        pre .err { background-color: #FCC; }

        /* RFC-2629 <texttable>s. */
        table.all, table.full, table.headers, table.none {
                font-size: small; text-align: center; border-width: 2px;
                vertical-align: top; border-collapse: collapse;
        }
        table.all, table.full { border-style: solid; border-color: black; }
        table.headers, table.none { border-style: none; }
        th {
                font-weight: bold; border-color: black;
                border-width: 2px 2px 3px 2px;
        }
        table.all th, table.full th { border-style: solid; }
        table.headers th { border-style: none none solid none; }
        table.none th { border-style: none; }
        table.all td {
                border-style: solid; border-color: #333;
                border-width: 1px 2px;
        }
        table.full td, table.headers td, table.none td { border-style: none; }

        hr { height: 1px; }
        hr.insert {
                width: 80%; border-style: none; border-width: 0;
                color: #CCC; background-color: #CCC;
        }
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Network Working Group</td><td class="header">J. Gregorio, Ed.</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">Google</td></tr>
<tr><td class="header">Intended status: Standards Track</td><td class="header">September 11, 2008</td></tr>
<tr><td class="header">Expires: March 15, 2009</td><td class="header">&nbsp;</td></tr>
</table></td></tr></table>
<h1><br />AtomPub Multipart Media Resource Creation<br />draft-gregorio-atompub-multipart-04</h1>

<h3>Status of this Memo</h3>
<p>
By submitting this Internet-Draft,
each author represents that any applicable patent or other IPR claims of which
he or she is aware have been or will be disclosed,
and any of which he or she becomes aware will be disclosed,
in accordance with Section&nbsp;6 of BCP&nbsp;79.</p>
<p>
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.
Note that other groups may also distribute working documents as
Internet-Drafts.</p>
<p>
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to cite
them other than as &ldquo;work in progress.&rdquo;</p>
<p>
The list of current Internet-Drafts can be accessed at
<a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p>
<p>
The list of Internet-Draft Shadow Directories can be accessed at
<a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p>
<p>
This Internet-Draft will expire on March 15, 2009.</p>

<h3>Abstract</h3>

<p>
	This specification defines how an Atom Publishing Protocol
	collection may process multipart/related requests
	and also defines how a service announces that it accepts
	multipart/related entities.
      
</p>
<h3>Editorial Note</h3>

<p>
	To provide feedback on this Internet-Draft, join the
	<a href='http://www.imc.org/atom-protocol/'>Atom Protocol mailing
	list (http://www.imc.org/atom-protocol/)</a>.
      
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>&nbsp;
Introduction<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor2">1.1.</a>&nbsp;
Notational Conventions<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor3">1.2.</a>&nbsp;
Design Considerations<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor4">1.3.</a>&nbsp;
Applicability<br />
<a href="#anchor5">2.</a>&nbsp;
Terminology<br />
<a href="#anchor6">3.</a>&nbsp;
Multipart Representations<br />
<a href="#anchor7">4.</a>&nbsp;
Server Processing<br />
<a href="#servicedoc">5.</a>&nbsp;
Service Document Extension<br />
<a href="#anchor8">6.</a>&nbsp;
Examples<br />
<a href="#anchor9">7.</a>&nbsp;
Security Considerations<br />
<a href="#iana">8.</a>&nbsp;
IANA Considerations<br />
<a href="#rfc.references1">9.</a>&nbsp;
Normative References<br />
<a href="#rfc.authors">&#167;</a>&nbsp;
Author's Address<br />
<a href="#rfc.copyright">&#167;</a>&nbsp;
Intellectual Property and Copyright Statements<br />
</p>
<br clear="all" />

<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.&nbsp;
Introduction</h3>

<p>
	The Atom Publishing Protocol <a class='info' href='#RFC5023'>[RFC5023]<span> (</span><span class='info'>Gregorio, J. and B. de hOra, &ldquo;The Atom Publishing Protocol,&rdquo; October&nbsp;2007.</span><span>)</span></a> defines Media 
	Collections and how to create
	a Media Resource by POSTing the media to the Media Collection. RFC 5023 
	does not define handling multipart/related <a class='info' href='#RFC2387'>[RFC2387]<span> (</span><span class='info'>Levinson, E., &ldquo;The MIME Multipart/Related Content-type,&rdquo; August&nbsp;1998.</span><span>)</span></a> 
	representations nor does it 
	specify how the acceptance of such representations should be 
	advertised in the Service Document. This specification covers both the 
	processing and the Service Document aspects of handling multipart/related content.
      
</p>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.1.1"></a><h3>1.1.&nbsp;
Notational Conventions</h3>

<p>
	  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
	  "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
	  "MAY", and "OPTIONAL" in this document are to be
	  interpreted as described in <a class='info' href='#RFC2119'>[RFC2119]<span> (</span><span class='info'>Bradner, S., &ldquo;Key words for use in RFCs to Indicate Requirement Levels,&rdquo; March&nbsp;1997.</span><span>)</span></a>.
	
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.1.2"></a><h3>1.2.&nbsp;
Design Considerations</h3>

<p>
	  The primary objective of multipart/related POSTs is to 
	  reduce round-trips for creating Media Resources. 
	  There are three round trips in the typical Media Resource
	  creation scenario; POST of the media, GET of the Media Link Entry, and subsequent
	  PUT of the updated Media Link Entry. This specification reduces that 
	  to just a single round-trip by allowing the client to package up
	  the media and the associated Media Link Entry into a single
	  multipart/related representation which is POSTed to the 
	  Media Collection.
	
</p>
<p>
	  The design of the handling of multipart/related representations
	  is aimed at backward compatibility, that is for non-multipart/related
	  aware clients to fully function. A second aim is to retain and 
	  utilize the expressiveness of the current app:accept element
	  in the Service Document. The last aim is to ease the burden on clients
	  by allowing the multipart representation to be constructed in an order
	  that is convenient for the client.
	
</p>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.1.3"></a><h3>1.3.&nbsp;
Applicability</h3>

<p>
	  The applicability of multipart/related representations
	  to AtomPub Collections is restricted to the creation of
	  new entries in Media collections. 
	  It does not specify the creation or use of a
	  resource that supports a GET to return the multipart/related representation
	  nor does it specify the creation or use of 
	  a resource that supports a PUT of a multipart/related 
	  representation.
	
</p>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.&nbsp;
Terminology</h3>

<p>
	The terms Collection, Media Resource, Media Link Entry, Foreign Markup,
	and Service Document are used as defined in <a class='info' href='#RFC5023'>[RFC5023]<span> (</span><span class='info'>Gregorio, J. and B. de hOra, &ldquo;The Atom Publishing Protocol,&rdquo; October&nbsp;2007.</span><span>)</span></a>.
	The term Object Root is used as defined in <a class='info' href='#RFC2387'>[RFC2387]<span> (</span><span class='info'>Levinson, E., &ldquo;The MIME Multipart/Related Content-type,&rdquo; August&nbsp;1998.</span><span>)</span></a>.
      
</p>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.&nbsp;
Multipart Representations</h3>

<p>
	This section covers the constraints on a multipart/related 
	representation sent to a Media Collection. <a class='info' href='#servicedoc'>Section&nbsp;5<span> (</span><span class='info'>Service Document Extension</span><span>)</span></a>
	covers how a client discovers that a Media Collection accepts
	multipart/related representations.
      
</p>
<p>
  There may be other specifications that define uses for
  multipart representations in the AtomPub context; this specification
  only describes one particular representation and how to use it in the
  media-resource creation process.
  Follow-on multipart/related specifications will have to define 
  a method by which a server can differentiate which 
  specification is in force, which is beyond the scope of this document.
      
</p>
<p>
	A multipart/related POST to a Media Collection MUST be a valid
	multipart/related representation as defined by <a class='info' href='#RFC2387'>[RFC2387]<span> (</span><span class='info'>Levinson, E., &ldquo;The MIME Multipart/Related Content-type,&rdquo; August&nbsp;1998.</span><span>)</span></a>
	and MUST contain two body parts. One, referred to as the Entry Part,
	MUST be an Atom Entry with a media type of 'application/atom+xml'
	or 'application/atom+xml;type=entry'. The other, referred to as the
	Media Part, MUST be of a media type acceptable to the collection.
	The object root MUST be the Entry Part. The Entry Part's
	atom:content element MUST have a 'src' attribute whose value is
	the URI of the related media in the Media Part. The 'src'
	attribute value MUST be a 'cid:' URI as defined by
	<a class='info' href='#RFC2392'>[RFC2392]<span> (</span><span class='info'>Levinson, E., &ldquo;Content-ID and Message-ID Uniform Resource Locators,&rdquo; August&nbsp;1998.</span><span>)</span></a>.
	The Content-Type: header of the POST request MUST specify
	"application/atom+xml;type=entry" or "application/atom+xml".
      
</p>
<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.&nbsp;
Server Processing</h3>

<p>
	A successful POST of a multipart/related representation to a Media
	Collection causes several resource-creation processes to occur as
	described in <a class='info' href='#RFC5023'>[RFC5023]<span> (</span><span class='info'>Gregorio, J. and B. de hOra, &ldquo;The Atom Publishing Protocol,&rdquo; October&nbsp;2007.</span><span>)</span></a>.
	The Media Part is used to create a Media Resource as if it had been
	posted as a request body to the collection as described in section
	9.6, and the Entry Part is used to create the corresponding Media
	Link Entry.  Assuming these two steps are successful, the server
	returns a 201 status code and a Location: header pointing to the
	newly created Media Link Entry. 
	The applicable rules from <a class='info' href='#RFC5023'>[RFC5023]<span> (</span><span class='info'>Gregorio, J. and B. de hOra, &ldquo;The Atom Publishing Protocol,&rdquo; October&nbsp;2007.</span><span>)</span></a> MUST be followed,
	including Slug: header	processing.
      
</p>
<p>
	While a multipart/related request replaces three round trips in the 
	typical Media Resource creation scenario, AtomPub has no mechanism to report
	partial success.  Thus, the handling of a 
	multipart/related request by the server MUST be atomic; that is, 
	either succeed with a 201 Created status code, or return an error
	status code. 
      
</p>
<a name="servicedoc"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.&nbsp;
Service Document Extension</h3>

<p>

  	An AtomPub service announces that it will accept multipart/related POSTs
 	by an extension to the app:accept element. The "alternate" attribute's
 	value MUST be one or more tokens, space-separated if more than one.
 	The only token defined by 
  	this specification is "multipart-related". The presence of the 
 	"multipart-related" token in the 'alternate' attribute's value indicates
 	that the collection accepts multipart/related POSTs whose
 	Media Part has a content-type matching that specified in the
 	app:accept element. The following example indicates a
  	collection that allows the creation of resources with 
  	the Ogg Bitstream Format and will also accept them in multipart form.

	</p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
&lt;app:accept alternate="multipart-related"&gt;application/ogg&lt;/app:accept&gt;</pre></div><p>

      
</p>
<p>
	The 'alternate' attribute is foreign markup and will be ignored
	by clients that do not understand multipart/related uploads.
	In addition it permits the full range of the app:accept element 
	to be used. The following indicates that the collection accepts
	any image media type and will also accept them in multipart
	form.

	</p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
&lt;app:accept alternate="multipart-related"&gt;image/*&lt;/app:accept&gt;</pre></div><p>

      
</p>
<p>
	The 'alternate' attribute allows clients that are unaware 
	of multipart/related to continue to operate as normal since
	the alternate attribute is foreign markup.
	The alternative, which is to put a multipart/related media type
	in the app:accept element, loses flexibility since the 
	'type' parameter to the multipart/related media type accepts
	only media types and not media ranges.
      
</p>
<a name="anchor8"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.&nbsp;
Examples</h3>

<p>
	Here is an example service document that 
	contains two media collections. The first collection
	accepts multipart/related POSTs for video media types only.
        It does not accept multipart/related POSTs for audio or 
        text. The second collection accepts multipart/related POSTs
	for image/gif and image/png media types.
      
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
   &lt;?xml version="1.0" encoding='utf-8'?&gt;
   &lt;service xmlns="http://www.w3.org/2007/app"
            xmlns:atom="http://www.w3.org/2005/Atom"&gt;
     &lt;workspace&gt;
       &lt;atom:title&gt;Media Collections&lt;/atom:title&gt;
       &lt;collection
           href="http://example.org/blog/main" &gt;
         &lt;atom:title&gt;Mostly Media&lt;/atom:title&gt;
         &lt;accept alternate="multipart-related"&gt;video/*&lt;/accept&gt;
         &lt;accept alternate="" &gt;text/*&lt;/accept&gt;
         &lt;accept              &gt;audio/*&lt;/accept&gt;
       &lt;/collection&gt;
       &lt;collection
           href="http://example.org/blog/pic" &gt;
         &lt;atom:title&gt;Pictures Only&lt;/atom:title&gt;
         &lt;accept alternate="multipart-related"&gt;image/png&lt;/accept&gt;
         &lt;accept alternate="multipart-related"&gt;image/gif&lt;/accept&gt;
       &lt;/collection&gt;
     &lt;/workspace&gt;
   &lt;/service&gt;
</pre></div>
<p>
	  Here is an example interaction of a client creating
	  a new Media Resource in the Pictures Only media collection
	  using a png image in a multipart/related representation.
	
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
POST /blog/pic HTTP/1.1
Host: example.org
Content-Length: nnnn
Content-Type: multipart/related;
       boundary="===============1605871705==";
       type="application/atom+xml"
Slug: The Beach
MIME-Version: 1.0

Media Post
--===============1605871705==
Content-Type: application/atom+xml; charset="utf-8"
MIME-Version: 1.0

&lt;?xml version="1.0"?&gt;
&lt;entry xmlns="http://www.w3.org/2005/Atom"&gt;
  &lt;title&gt;The Beach&lt;/title&gt;
  &lt;id&gt;urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a&lt;/id&gt;
  &lt;updated&gt;2005-10-07T17:17:08Z&lt;/updated&gt;
  &lt;author&gt;&lt;name&gt;Daffy&lt;/name&gt;&lt;/author&gt;
  &lt;summary type="text"&gt;
      A nice sunset picture over the water.
  &lt;/summary&gt;
  &lt;content src="cid:99334422@example.com"
           type="image/gif" /&gt;
&lt;/entry&gt;
--===============1605871705==
Content-Type: image/gif
MIME-Version: 1.0
Content-ID: &lt;99334422@example.com&gt;

GIF89a...binary image data...
--===============1605871705==--
</pre></div>
<p>
	 If the request was successful the response might look like:
       
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
HTTP/1.1 201 Created
Date: Fri, 7 Oct 2005 17:17:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
Location: http://example.org/media/edit/the_beach.atom

&lt;?xml version="1.0"?&gt;
&lt;entry xmlns="http://www.w3.org/2005/Atom"&gt;
  &lt;title&gt;The Beach&lt;/title&gt;
  &lt;id&gt;urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a&lt;/id&gt;
  &lt;updated&gt;2005-10-07T17:17:08Z&lt;/updated&gt;
  &lt;author&gt;&lt;name&gt;Daffy&lt;/name&gt;&lt;/author&gt;
  &lt;summary type="text"&gt;
      A nice sunset picture over the water.
  &lt;/summary&gt;
  &lt;content type="image/png"
      src="http://media.example.org/the_beach.png"/&gt;
  &lt;link rel="edit-media" type="image/png"
      href="http://media.example.org/edit/the_beach.png" /&gt;
  &lt;link rel="edit"
      href="http://example.org/media/edit/the_beach.atom" /&gt;
&lt;/entry&gt;
</pre></div>
<p>
	The initial request does not have to have the Entry Part first to 
        indicate that it is the object root, it's location
        can be indicated by the 'start' attribute, as in this example.
      
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
POST /blog/pic HTTP/1.1
Host: example.org
Content-Length: nnnn
Content-Type: multipart/related;
       boundary="===============1605871705==";
       type="application/atom+xml";
       start="&lt;10101033@example.com&gt;"
Slug: The Beach
MIME-Version: 1.0

Media Post
--===============1605871705==
Content-Type: image/gif
MIME-Version: 1.0
Content-ID: &lt;99334422@example.com&gt;

GIF89a...binary image data...
--===============1605871705==
Content-Type: application/atom+xml; charset="utf-8"
MIME-Version: 1.0
Content-ID: &lt;10101033@example.com&gt;

&lt;?xml version="1.0"?&gt;
&lt;entry xmlns="http://www.w3.org/2005/Atom"&gt;
  &lt;title&gt;The Beach&lt;/title&gt;
  &lt;id&gt;urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a&lt;/id&gt;
  &lt;updated&gt;2005-10-07T17:17:08Z&lt;/updated&gt;
  &lt;author&gt;&lt;name&gt;Daffy&lt;/name&gt;&lt;/author&gt;
  &lt;summary type="text"&gt;
      A nice sunset picture over the water.
  &lt;/summary&gt;
  &lt;content src="cid:99334422@example.com"
           type="image/gif" /&gt;
&lt;/entry&gt;
--===============1605871705==--
</pre></div>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.7"></a><h3>7.&nbsp;
Security Considerations</h3>

<p>
	The security considerations are the same as delineated in <a class='info' href='#RFC5023'>[RFC5023]<span> (</span><span class='info'>Gregorio, J. and B. de hOra, &ldquo;The Atom Publishing Protocol,&rdquo; October&nbsp;2007.</span><span>)</span></a>.
      
</p>
<a name="iana"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8"></a><h3>8.&nbsp;
IANA Considerations</h3>

<p>
	No IANA actions are required by this document.
      
</p>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<h3>9.&nbsp;Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, &ldquo;<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,&rdquo; BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997 (<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2387">[RFC2387]</a></td>
<td class="author-text"><a href="mailto:XIson@cnj.digex.com">Levinson, E.</a>, &ldquo;<a href="http://tools.ietf.org/html/rfc2387">The MIME Multipart/Related Content-type</a>,&rdquo; RFC&nbsp;2387, August&nbsp;1998 (<a href="ftp://ftp.isi.edu/in-notes/rfc2387.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2387.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2387.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2392">[RFC2392]</a></td>
<td class="author-text"><a href="mailto:XIson@cnj.digex.net">Levinson, E.</a>, &ldquo;<a href="http://tools.ietf.org/html/rfc2392">Content-ID and Message-ID Uniform Resource Locators</a>,&rdquo; RFC&nbsp;2392, August&nbsp;1998 (<a href="ftp://ftp.isi.edu/in-notes/rfc2392.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2392.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC5023">[RFC5023]</a></td>
<td class="author-text">Gregorio, J. and B. de hOra, &ldquo;<a href="http://tools.ietf.org/html/rfc5023">The Atom Publishing Protocol</a>,&rdquo; RFC&nbsp;5023, October&nbsp;2007 (<a href="ftp://ftp.isi.edu/in-notes/rfc5023.txt">TXT</a>).</td></tr>
</table>

<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<h3>Author's Address</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Joe Gregorio (editor)</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Google</td></tr>
<tr><td class="author" align="right">Email:&nbsp;</td>
<td class="author-text"><a href="mailto:joe@bitworking.org">joe@bitworking.org</a></td></tr>
<tr><td class="author" align="right">URI:&nbsp;</td>
<td class="author-text"><a href="http://bitworking.org/">http://bitworking.org/</a></td></tr>
</table>
<a name="rfc.copyright"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<h3>Full Copyright Statement</h3>
<p class='copyright'>
Copyright &copy; The IETF Trust (2008).</p>
<p class='copyright'>
This document is subject to the rights,
licenses and restrictions contained in BCP&nbsp;78,
and except as set forth therein,
the authors retain all their rights.</p>
<p class='copyright'>
This document and the information contained herein are provided
on an &ldquo;AS IS&rdquo; basis and THE CONTRIBUTOR,
THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.</p>
<h3>Intellectual Property</h3>
<p class='copyright'>
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Information on the procedures with respect to
rights in RFC documents can be found in BCP&nbsp;78 and BCP&nbsp;79.</p>
<p class='copyright'>
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available,
or the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at <a href='http://www.ietf.org/ipr'>http://www.ietf.org/ipr</a>.</p>
<p class='copyright'>
The IETF invites any interested party to bring to its attention
any copyrights,
patents or patent applications,
or other
proprietary rights that may cover technology that may be required
to implement this standard.
Please address the information to the IETF at <a href='mailto:ietf-ipr@ietf.org'>ietf-ipr@ietf.org</a>.</p>
</body></html>
